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REMARKS 

This communication is responsive to the Final Office Action dated June 23, 2009. The 
claims have not been amended in any way. Claims 1-91 are pending. Applicant request 
reconsideration of the rejections in light of the arguments put forth below. 

Claim Rejection Under 35 U.S.C. 8 103 

In the Final Office Action, the Examiner rejected claims 1-6, 8, 12, 14, 16, 18-21, 24, 
25, 29, 31-34, 36, 39, 41^3, 46-48, 50, 55-57, 59, 63, 65-67, 72, 75, 78, 81, 84, 87 and 90 
under 35 U.S.C. § 103(a) as being unpatentable over U.S. Patent Application Publication No. 
2005/0175341 to Ovadia ("Ovadia") in view of U.S. Patent No. 6,775,280 to Ma ("Ma"). The 
Examiner also rejected claims 7, 1 1, 15, 17. 22, 23, 28, 29, 35, 38, 40, 45, 49, 52, 54, 58, 62, 64, 
70, 73, 76, 79, 82, 85, 88 and 91 under 35 U.S.C. § 103(a) as being unpatentable over Ovadia in 
view of Ma and further in view of U.S. Patent No. 7,139,242 to Bays ("Bays"). The Examiner 
also rejected claims 13 and 30 under 35 U.S.C. § 103(a) as being unpatentable over Ovadia in 
view of Ma and further in view of U.S. Patent No. 6,339,595 to Rekhter ("Rekhter"). The 
Examiner also rejected claims 9, 10, 26, 27, 37, 44, 51, 53, 60, 61, 68, 69, 71, 74, 77, 80, 83, 86 
and 89 under 35 U.S.C. § 103(a) as being unpatentable over Ovadia in view of Ma and further in 
view of U.S. Patent Application Publication No. 2003/0076248 to Larson ("Larson"). Applicant 
respectfully traverses these rejections. Even when combined, the applied references fail to 
disclose or suggest all the features recited in Applicant's claims, and provide no teaching that 
would have suggested a reason for modification to include the claimed features. 
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For example, the combination of Ovadia and Ma fails to disclose or suggest all the 

elements of claim 1. Claim 1 recites the following: 

A method for distributing traffic flow criteria between network 
devices, the method comprising: 

defining a flow specification data type for a routing 
protocol, wherein the flow specification data type allows a variable 
number of packet flow attributes to be specified for a packet flow 
through a network; 

generating, with a first routing device, a message that 
encodes routing topology information, wherein the routing 
topology information defines at least one route between a first 
network device and a second network device, and traffic flow 
criteria specifying the packet flow in accordance with the flow 
specification data type; and 

communicating, with the first routing device, the message 
to a second routing device to direct the second routing device to 
control network traffic based on the traffic flow criteria, 

wherein the traffic flow criteria comprises source 
information that identifies a source network device of the packet 
flow. 

Ovadia fails to disclose or suggest "defining a flow specification data type for a routing 
protocol, wherein the flow specification data type allows a variable number of packet flow 
attributes to be specified for a packet flow through a network," particularly in combination with 
the other elements recited in claim 1 . In the Office Action, 1 the Examiner indicated that 
paragraph [0170] Ovadia disclosed this element. Applicant respectfully disagrees. Paragraph 
[0170] of Ovadia recites the following: 

[0170] BGP is a path-vector protocol that works by send- 
ing route advertisements. Routing information is stored at 
each BGP router as a combination of destination and 
attributes of the path to that destination. A route advertise- 
ment indicates that reachability of a network (i.e., a network 
address and a netmask representing block of contiguous IP 
address. Besides the reachable network and the IP address of 
the router that is used to reach this network (known as the 
next hop), a route advertisement also contains the AS path 
attribute, which contains the list of ail the transit AS's that 
may be used to reach the announced network. The length of 
the AS path may be considered as the route metric. 



' Office Action, dated June 23, 2009, page 2. 
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As seen above, there is no teaching or suggestion in paragraph [0170] of Ovadia to define a flow 
specification data type for a routing protocol, wherein the flow specification data type allows a 
variable number of packet flow attributes to be specified for a packet flow through a network, as 
required by claim 1. Rather, paragraph [0170] simply discloses standard Border Gateway 
Protocol (BGP). The Examiner has not introduced substantial evidence to establish that standard 
BGP includes a flow specification data type as claimed by the Applicant. 

To be clear, Ovadia does discloses extending BGP 2 and, in particular, extending the BGP 
UPDATE message. 3 For example, Ovadia discloses at paragraph [0171] that "the standard BGP 
needs to be extended to convey the necessary lightpath routing information to the BGP routers. 
The goal is to leverage the existing BGP properties, but extend them to meet the routing 
requirements of PBS networks." As seen in FIG. 17b, the extended BGP UPDATE message 
includes fields such as an "available wavelength attribute" field and an "available fiber attribute" 
field. These fields do not, however, define a flow specification data type for a routing protocol, 
wherein the flow specification data type allows a variable number of packet flow attributes to be 
specified for a packet flow through a network, as required by claim 1 . Rather, these attributes 
refer to the optical links 904 that connect various switching PBS switching modules, 4 as seen 
below in FIG. 9b of Ovadia: 



2 Ovadia, paragraph [0164], 

3 Id at paragraphs [0171], [0173] and FIG. 17b. 
4 14 at paragraph [0161]. 
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Fig. 9b 




9006 



Specific attributes of an optical link 904 (i.e., the physical communication medium) such as a 
wavelength attribute and a fiber attribute do not define a flow specification data type for a 
routing protocol, wherein the flow specification data type allows a variable number of packet 
flow attributes to be specified for a packet flow through a network, as in claim 1 . To be sure, 
wavelength attributes and fiber attributes are not attributes of packet flows. As stated in 
Applicant's specification at paragraph [0045], packet flow criteria may include "source address, 
destination address, source port, destination port, protocol, quality of service (QoS) level, and/or 
other flow criteria." The wavelength attributes and a fiber attributes of Ovadia simply refer to 
the lightpath characteristics of the optical links 904 connecting neighboring Server Area 
Networks (SANs) and are unrelated to attributes of specific flows of packets or other data units 
flowing over the link. Lightpath characteristics of an optical are not packet flow attributes. 

Also with respect to claim 1, the Office Action further asserted 5 that Ovadia discloses 
communicating, with the first routing device, the message to a second routing device to direct the 
second routing device to control network traffic based on the traffic flow criteria, wherein the 
traffic flow criteria comprises source information that identifies a source network device of the 

5 Office Action, dated June 23, 2009, page 2. 
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packet flow, as required in claim 1, at paragraphs [01 70]-[01 7 1 ] and FIG. 11. Applicant 

respectfully disagrees. FIG. 1 1 of Ovadia is simply the format of a Fibre-Channel frame. 6 As 

stated in Ovadia, 7 

The basic building blocks of an FC connection are the Frames. The 
Frames contain the information to be transmitted (i.e., payload), 
the address of the source and destination ports, and link control 
information. Frames are broadly categorized as Data frames and 
Link control frames. Data frames may be used as Link Data 
frames and DeviceData frames, link control frames are classified 
as Acknowledge (ACK) and Link_Response (Busy and Reject) 
frames. The primary function of the Fabric is to receive the Frames 
from the source port and route them to the destination port. It is the 
FC- 2 layer's responsibility to break the data to be transmitted into 
Frame size, and reassemble the Frames. 

The source and destination information described above in paragraph [0121] of Ovadia does not 
relate to a routing message at all but instead traffic carried by a link. That is, the source and 
destination information is not traffic flow criteria carried by a routing message and that 
comprises source information that identifies a source network device of a packet flow, as 
required by claim 1 . Rather, the source and destination information described is merely standard 
source and destination information of a frame necessary for that same frame to reach a 
destination address and convey the source address of the originating device. In claim 1, the 
traffic flow criteria specify the packet flow in accordance with the flow specification data type. 
In no manner does Ovadia disclose or suggest such traffic flow criteria or incorporation of the 
traffic flow criteria in a routing message. 

Ma discloses techniques for routing data that "provide load-balancing while, at the same 
time, satisfying QoS requirements." 8 The addition of any alleged disclosure in Ma with respect 
to routing topology information that defines at least one route between a first network device and 
a second network device does nothing to remedy the deficiencies of Ovadia. As such, claim 1 is 
non-obvious over the applied references. 



6 Ovadia, paragraph [0026]. 

7 Id at paragraph [0121]. 

8 Ma, col. 2, lines 2-10. 
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Claims 16, 32, 39, 46, 55, and 63 recite elements similar to those recited in claim 1. For 
reasons similar to those presented above with respect to claim 1, claims 16, 32, 39, 46, 55, and 
63 are also non-obvious over the applied references. 

Each of claims 2-6, 8, 12, 14, 18-21. 24, 25, 29, 31, 33, 34, 36, 41-43, 47, 48, 50, 56, 57, 
59, 65-67, 72, 75, 78, 81, 84, 87 and 90 depend either directly or indirectly from one of claims 1, 
16, 32, 39, 46, 55, and 63. By virtue of their dependency, claims 2-6, 8, 12, 14, 18-21, 24, 25, 
29, 31, 33, 34, 36, 41-43, 47, 48, 50, 56, 57. 59, 65-67, 72, 75, 78, 81, 84, 87 and 90 are non- 
obvious over the applied references. 

In addition, each of claims 7, 1 1, 15, 17, 22, 23, 28, 29, 35, 38, 40, 45, 49, 52, 54, 58, 62, 
64, 70, 73, 76, 79, 82, 85, 88 and 91 depend either directly or indirectly from one of claims 1, 16, 
32, 39, 46, 55, and 63. By virtue of their dependency, claims 7, 1 1, 15, 17, 22, 23, 28, 29, 35, 38, 
40, 45, 49, 52, 54, 58, 62, 64, 70, 73, 76, 79, 82, 85, 88 and 91 are non-obvious over the 
combination of Ovadia and Ma. The addition of any alleged disclosure in Bays with respect to 
the features of claims 7, 11, 15, 17, 22, 23, 28, 29, 35, 38, 40, 45, 49, 52, 54, 58, 62, 64, 70, 73, 
76, 79, 82, 85, 88 and 91 does nothing to remedy the deficiencies of Ovadia. 

Bays discloses techniques that allow a routing control device to perform load sharing of 
traffic flows across network devices. The techniques disclosed in Bays make use of BGP in a 
conventional manner. For example, Bays states at col. 7, line 66 -col. 8, line 4, "Once a control 
peering session has been established, routing control device 20 controls routing in a routing 
system 30 by injecting routes with better metrics than the ones installed locally. Metrics used 
include local-preference, weight, multi-exit discriminator, and/or others as defined by the BGP 
protocol '' (Emphasis added.) And, at col. 8, lines 42-46, Bays states, "Since routing control 
device 20 is simply a BGP peer using the standard protocol, if the peering session between 
routing control device 20 and the routing system 30 fails all modified routes are flushed from 
the routing system RIB." (Emphasis added.) The techniques disclosed in Bays do not teach or 
suggest BGP messages that comprise "traffic flow criteria" in accordance with any "flow 
specification data type," as in claims 1,16, 32, 39, 46, 55, and 63. In contrast, embodiments of 
the present invention allow BGP to be extended to include these additional "traffic flow criteria" 
that can be used, for example, to specify individual flows of packets from a source device to a 
destination device. In exchanging routing information, the BGP-enabled routers of Bays do not 
exchange traffic flow criteria that specify individual packet flows. 
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Further, claims 13 and 30 depend indirectly from claims 1 and 16. By virtue of their 
dependency, claims 13 and 30 are non-obvious over the combination of Ovadia and Ma. The 
addition of any alleged disclosure in Rekhter with respect to the features of claims 13 and 30 
does nothing to remedy the deficiencies of Ovadia. 

Rekhter is directed to providing routing for private wide-area networks. 9 Rekhter 
discloses techniques that allow provider edge routers to add internal-routing fields to received 
packets thereby eliminating the need of transit routers to maintain VPN-specific information 
stored by the edge routers. 10 In particular, Rekhter discloses adding an egress router field and 
egress channel field to a packet received at an edge router. As stated in Rekhter at col. 6, line 61 
- col. 7, line 5, 

The egress-router field takes the form of a tag that P 2 can map to 
the next hop in the route to the egress edge router PE 1 , upon 
which the transit routers can base their routing decisions without 
requiring knowledge of the VPN involved. The egress-channel 
field takes the form of a tag that PE 1 can interpret as specifying its 
interface with CE 1 or as otherwise representing the channel that 
links it to VPN V. 

The techniques disclosed in Rekhter do not teach or suggest BGP messages that comprise "traffic 
flow criteria" in accordance with any "flow specification data type," as in claims 1 and 16. 

Further, each of claims 9, 10, 26, 27, 37, 44, 51, 53, 60, 61, 68, 69, 71, 74, 77, 80, 83, 86 
and 89 depend from one of claims 1,16, 32, 39, 46, 55, 63. By virtue of their dependency, 
claims 9, 10, 26, 27, 37, 44, 51, 53, 60, 61, 68, 69, 71, 74, 77, 80, 83, 86 and 89 are non-obvious 
over Ovadia and Ma. The addition of any alleged disclosure in Larson with respect to the 
features of claims 9, 10, 26, 27, 37, 44, 51, 53, 60, 61, 68, 69, 71, 74, 77, 80, 83, 86 and 89 does 
nothing to remedy the deficiencies of Ovadia. In addition, Larson fails to disclose or suggest all 
the elements of claims 9, 10, 26, 27, 37, 44, 51, 53, 60, 61, 68, 69, 71, 74, 77, 80, 83, 86 and 89, 
some of which are detailed below. 

Claim 9 requires that defining a flow specification data type comprises redefining a 
preexisting data type of the routing protocol to define the flow specification data type. There is 
no suggestion in Larson that a preexisting data type for a routing protocol be somehow redefined 
in a manner that allows a specific packet flow to be defined. Larson is directed to techniques for 

9 Rekhter, col. 1, lines 7-8. 

10 Id. at col. 6, line 51- col. 7, line 14. 
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transmitting and storing data using an enhanced multidecimal encoding system. 1 1 Contrary to the 
Examiner's assertion, paragraph [0041] of Larson does not teach redefining a preexisting data 
type of the routing protocol to define the flow specification data type. That is, translation from 
binary to hexadecimal is not redefining a preexisting data type of the routing protocol to define 
the flow specification data type, as in claim 9. Rather, a redefined flow specification data type is 
shown in FIG. 3A of Applicant's disclosure: 
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FIG. 3A 



In no manner does translating from binary to hexadecimal, or to any other multidecimal format 
constitute redefining a data type, as asserted by the Examiner. As such, Larson fails to disclose 
or suggest the elements of claim 9. 

In addition, claim 10 requires that defining a flow specification data type comprises 
defining the flow specification data type as an application-specific data type in accordance with 
the routing protocol. There is no suggestion in Larson that a flow specification data type of a 
routing message is defined as an application-specific data type in accordance with the routing 
protocol. Contrary to the Examiner's assertion, the abstract of Larson does not teach defining a 
flow specification data type as an application-specific data type in accordance with the routing 
protocol. Larson's abstract is presented immediately below: 



" Larson, paragraph [0016]. 
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(57) ABSTRACT 

A system for and method of transmitting and storing data 
using mult idcdmal encoding. A binary data stream is 
encoded into a mtiltidecimai data stream. Distinct frequen- 
cies arc then assigned to characters in the multidccimal data 
stream tor transmitting the multidccimal character informa- 
tion. Individual frequencies, or combinations of frequencies, 
may be assigned to each multidccimal character to be 
transmitted, through various methods. The various mul- 
tidccimal transmission schemes described herein may be 
employed in any of several transmission systems, such as 
fiber optics networks, analog transmission systems, DSL 
systems, cable modem systems, wireless communication 
systems, or any other suitable data transmission systems. 
Multidccimal data may also be stored in various storage 
media, such as CD-ROMs, DVDs, or RAM. 



In no manner does Larson's abstract disclose routing protocols or application-specific data types, 
much less that defining a flow specification data type comprises defining the flow specification 
data type as an application-specific data type in accordance with the routing protocol, as required 
by claim 10. As such, Larson fails to disclose or suggest the elements of claim 10. 

For at least these reasons, the Examiner has failed to establish a prima facie case for non- 
patentability of Applicant's claims l-91under 35 U.S.C. § 103(a). Withdrawal of this rejection is 
requested. 

CONCLUSION 

All claims in this application are in condition for allowance. Applicant respectfully 
requests reconsideration and prompt allowance of all pending claims. Please charge any 
additional fees or credit any overpayment to deposit account number 50-1778. The Examiner is 
invited to telephone the below-signed attorney to discuss this application. 

Date: 

September 23. 2009 

SHUMAKER & SIEFFERT, P.A 
1625 Radio Drive, Suite 300 
Woodbury, Minnesota 55125 
Telephone: 651.286.8364 
Facsimile: 651.735.1102 
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